1. The Field of the Invention
The present invention relates to establishing a secure connection between two computers when transferring data using a transport protocol. More specifically, the present invention provides for generating an initial sequence number in the manner that prevents a local server from being attacked while maintaining reliable data transfer.
2. Background and Related Art
Computer systems and related technology effect many aspects of society. Indeed, the computer systems ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of the computer system were performed manually. Increasingly, separate computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. As a result, many of the tasks performed at a computer system (e.g., accessing electronic mail and web browsing) include electronic communication with one or more other computer systems via a computer network (e.g., the Internet).
Often, electronic communication on a computer network includes a client computer system (hereinafter referred to as a “remote client”) requesting access to a service (e.g., electronic mail or a web page) at a server computer system (hereinafter referred to as a “local server”). Before granting the client access to the service, the server may issue a challenge to the client requiring the client to prove it's identity to the server. A challenge may be a relatively simple one, for example, challenging a user at the client to enter username and password. On the other hand, a challenge may be more complex, such as challenging the client to correctly perform a complex handshake sequence.
One reliable data transport protocol that uses a handshake sequence when challenging a client is known as transmission control protocol (TCP). TCP is used for establishing bidirectional streams, like those used for remote terminal connections (established with telnet or rlogin utilities). TCP is also used for transferring large amounts of data, for example, with file transfer protocol (FFP) or connecting to a Web server.
Unlike most other parts of the Internet Protocol suite (such as Internet Control Message Protocol (ICMP) or User Datagram Protocol (UDP)), TCP establishes a connection between the local and remote site. As mentioned above, these TCP connections are generally reliable; therefore, a challenge to the client in the form of a handshake is used to prevent attackers from gaining access to the connection.
FIG. 1 illustrates a typical TCP three way handshake, i.e., the exchange of three messages, used to establish a connection between a remote 105 client and a local server 110. The remote client 105 sends an initial synchronization (SYN) segment, which includes an initial sequence number (ISN), shown here as ISNc. The local server 110 responds with a SYN 125 comprising its own ISN (shown here as ISNs), and an acknowledgement (ACK) 120. This ACK 120 includes the ISNcreceived from the remote client 105 plus one, which among other things lets the remote client 105 know that the local server 110 received it's SYN.
Similar to the local server 110, when the client system 105 receives the SYN 125 and ACK 120 packet, it must send back its own ACK message 130, which will include the servers 110 ISNS plus one. The ISNs generated from the remote client 105 and the local server 110 used not only to assign sequence numbers to data packets exchanged between the two, but also as a way to ensure that each received the appropriate package and that each is communicating with who they initially believed to be communicating.
Many systems have statistical weaknesses in the methods that are used to generate random TCP initial sequence numbers, possibly allowing an attacker to hijack or close TCP sessions. For example, if an attacker knows or can predict the TCP initial sequence number, they may be able to close the TCP session, hijack it, or inject arbitrary data. In this type of attack, it is not necessary for the attacker to know a specific sequence number. The attacker can simply send a flood of packets that contain likely sequence numbers so that one or more packets which happen to contain a correct sequence number are likely to be accepted. If the set of possible sequence numbers is small enough, or if the sequence numbers can be predicted with some certainty, it becomes relatively simple for an attacker to send rogue packets set with correct sequence numbers.
To protect against these types of attacks, many operating systems use random number generators to choose TCP ISNs. There are, however, several inherent problems associated with current ISN random generators. For example, initial random generator attempted to solve the problem by creating ISNs that were fully random, i.e., there was no requirements for how the numbers should be chosen. The problem with this approach, however, is the potential for data collisions from competing sequence numbers that use the same connection identifier.
For example, a connection could initially be established by a remote client using a particular connection identifier (usually some combination of source/destination IP address and port). The client later gives that connection identifier up after sending its data, and another connection is made by either the same remote client or another remote client using the same connection identifier shortly thereafter. Because the ISN chosen for the subsequent connection was fully random, there is a potential for overlap of sequence numbers for data that was sent in the first connection but not yet received by the local server. To avoid this problem, some protocol standards require that initial sequence numbers be monotonically increasing (or decreasing), not fully random. (It is noted that monotonically increasing within the meaning of this application means a sequence of numbers that continue to increase in value-wrapping from the largest sequence number back to the smallest sequence number is considered monotonically increasing.)
FIG. 2 illustrates how one technique for creating ISNs that are independent of the connection. As shown, random ISNs for each connection are initially chosen without regard to the ISNs chosen for other connections. For example, the random number for a connection C1 215 may be a first value chosen randomly on a counter value 200. This value is independent of the initial random value chosen for connection C2 210 or the random value for connection C3 220. Once the connection is made and the random value for the ISN is determined, however, each subsequent random value is made to increase from the previous value. For example, the second random value R4 for connection C3 225 must be greater in value than the first random value R3 for the same connection C3 220. Likewise, the next random value R5 for the same connection C3 230 is increased in value over the subsequent random ISNs R3, R4 for connection C3 220, 225, respectively.
The problem associated with this approach, however, is that although the initial random ISN value for a particular connection was random, all subsequent ISN numbers were increased based on a fixed time value. For example, as shown in FIG. 2, even though the initial random ISN (R3) for connection C3 220 is random (as is the ISN for connections C1 and C2), subsequent ISNs R5, R4 (225, 230) for connection C3 are equally spaced based on a time factor Δt 205. Accordingly, similar to the original problems associated with early TCP implementations, if an attacker can determine any one of the ISN values at any one given time, the attacker may predict subsequent ISN values by simply knowing or guessing Δt, and the amount ISNs increasing over Δt, with a reasonable degree of certainty. In particular, because IP addresses are frequently shared among or dynamically assigned to multiple users over time, an attacker may use particular connection identifier determine what the ISN for that identifier is at that particular time, subsequently relinquish the connection identifier, and knowing Δt predict subsequent ISN and sequence numbers for that identifier to attack a TCP session. Accordingly, there exists a need for generating random ISN values on a per connection identifier basis.